home *** CD-ROM | disk | FTP | other *** search
/ Linux Cubed Series 7: Sunsite / Linux Cubed Series 7 - Sunsite Vol 1.iso / system / network / chat / reflect.000 / reflect / 3.0b3 / README.reflector.3.0b3.txt < prev    next >
Encoding:
Text File  |  1995-01-19  |  19.3 KB  |  552 lines
  1. Cornell Reflector Version 3.00B3
  2.  
  3. This is a BETA version of the newest release of the CU-SeeMe 
  4. reflector program, version 3.00B3.
  5.  
  6. Changes between 3.00B2 and 3.00B3
  7.  
  8. 1) Added default reflector messages for max-lurkers and 
  9.    max-senders.
  10.  
  11. 2) fixed several bugs having to do with supporting VAT
  12.    clients.
  13.  
  14. -----------
  15.  
  16. Changes between 3.00B1 and 3.00B2
  17.  
  18. All of the changes between versions B1 and B2 have been
  19. bug fixes - no new features have been added.  There are
  20. still some outstanding bugs that haven't been corrected in
  21. B2 and you should anticipate another bug fix version B3
  22. to be out in a week or two.
  23.  
  24. 1) The conference id feature was basically broken
  25.  
  26. 2) The MAX-SENDERS and MAX-LURKERS configuration
  27.    features had some problems.
  28.   
  29. 3) When using the Mbone tools vat and nv there
  30.    was a problem if a client went from being
  31.    a vat and nv client to just a vat client.
  32.  
  33. 4) The correct version number was not always being
  34.    set for nv clients, so sometimes when looking at
  35.    the version information on the CUSM window, it
  36.    would not say nv client.
  37.    
  38.  
  39.  
  40. fix a bug in the conference id
  41.  
  42.  fix a couple of bugs with the max senders and max lurkers when the
  43.  client made a transition without disconnecting
  44.  
  45. fix a bug in the calculation of the client count
  46.  
  47.  fix a bug in that when a client is both nv and
  48.     vat and the nv session disappears then the vat
  49.     session keeps the guys window up on the CUSM 
  50.     screaan because the seq numing in the make OCP
  51.     for vat clients routine was never being increamented.
  52.  
  53. 1/6 set the right version # in the OCP for vat OCP's
  54.  
  55. 1/6 fix a bug in the calculations of # of lurkers and
  56.     # of senders
  57.  
  58. If you are compiling this code on a machine without a 
  59. multicast kernel, you will have to remove the -DMULTI 
  60. definition from the makefile.  
  61.  
  62. If you are connecting reflectors together, make sure that all 
  63. the reflectors are using the same version.
  64.  
  65. Bug reports and or general comments can either be sent to the 
  66. CU-SeeMe bug list at cu-seeme-bugs@cornell.edu, or directly  
  67. to me, John Lynn, at John-A-Lynn@cornell.edu.
  68.  
  69. Reflector Operation
  70.  
  71. The reflector is started with a single optional parameter, 
  72. the configuration file name.  If no configuration file is 
  73. specified, the reflector tries to open the default 
  74. configuration file called reflect.conf.  If that file is not 
  75. found, then no configuration information is specified and the 
  76. default values for all configuration parameters are used.  
  77. The configuration file is an ASCII text file.  Each line 
  78. begins with a keyword which specifies the parameter  
  79. configured. Some of the keywords are followed by arguments 
  80. that specify the value(s) for that configuration parameter.  
  81. Any line which begins with a semicolon (;) is a comment line 
  82. and is ignored by the reflector.
  83.  
  84. The following are the configuration keywords and their 
  85. parameters if any exist.
  86.  
  87. DEBUG
  88.  
  89. Specifying DEBUG causes the reflector to print out a large 
  90. amount of debugging information.  This information is 
  91. probably not particularly meaningful to anyone but the 
  92. reflector programmer and will slow down the operation of the 
  93. reflector, so DEBUG in general should not be added to the 
  94. configuration.
  95.  
  96.  
  97. SELF-REFLECT
  98.  
  99. SELF-REFLECT causes the reflector to send your own CU-SeeMe 
  100. stream back to you.  This also is a sort of debugging aid, 
  101. allowing you to make sure your reflector is up and running. 
  102.  
  103.  
  104. REFMON ip-addr
  105.  
  106. REFMON is used to specify the IP address of the UNIX 
  107. workstation that is allowed to access the reflector using the 
  108. refmon application.  If no REFMON is specified in the 
  109. configuration, then a refmon application running on any 
  110. workstation will be allowed access to your reflector.  If the 
  111. IP address is specified as 0.0.0.0, then no refmon anywhere 
  112. will be granted access.  The refmon application is documented 
  113. later on   As refmon can be used to kill the reflector, it's 
  114. probably best to include this parameter in all configuration 
  115. files.
  116.  
  117.  
  118. CONF-ID conference-id msg-string
  119. //
  120.  
  121. Specifying CONF-ID allows you to have a measure of privacy on 
  122. a public reflector.  In any Mac version of CU-SeeMe above 
  123. 0.70 or any PC version above 0.34, the application will allow 
  124. the user to optionally specify a conference id when opening a 
  125. connection.  The default conference id is 0 which is also the 
  126. reflector's default conference id.  When the reflector is 
  127. configured, defaulted, or set to zero all user conference 
  128. ID's are accepted. If the reflector is configured with a 
  129. conference ID other then 0, then any incoming CU-SeeMe 
  130. conference id must match the conference id in the reflector.  
  131. The conference ID is a 16 bit value (range from 0 to 65535).  
  132. If the reflector's conference ID is less then 32768 (high bit 
  133. not on) and the conference ids do not match, then that 
  134. participant is not added to the conference.   If the 
  135. reflector's conference ID is between 32768 and 65535 (high 
  136. bit on) and the conference ids do not match, then that 
  137. participant is allowed to join the conference but is 
  138. prohibited from sending either audio or video.  To have a 
  139. private conference, without uninvited participants, you would 
  140. pick a random conference id in the appropriate range, add it 
  141. to the configuration file, make this number known to all of 
  142. your invited guests, and ask them to specify this conference 
  143. id when connecting to the reflector.  The msg string is an 
  144. ascii string terminated by a carriage return followed by two 
  145. back slashes.  This is the string that will appear on a 
  146. participant's screen if he tries to connect with the wrong 
  147. conference ID. Maximum length of msg-string is 80 characters 
  148. for this and all other msg-strings.  Also see CONF-MGR below.
  149.  
  150.  
  151. CONF-MGR ip-address
  152.  
  153. The CONF-MGR ip address, is the ip address of a participant 
  154. that is permitted to set the conference id when he connects.  
  155. This allows a designated participant to dynamically establish 
  156. a restricted conference without having to manually 
  157. reconfigure the reflector.  When the conference manager 
  158. connects to a reflector he can specify a non-zero conference 
  159. ID number.  All participants currently connected with this 
  160. correct ID number will remain connected.  All participants 
  161. currently connected with the wrong conference ID or zero will 
  162. be disconnected and the message string that was specified in 
  163. the CONF-ID configuration parameter will appear on their 
  164. screen (or they will have their sending halted, for ID > 
  165. 32768).  All future connection attempts will also have to 
  166. contain the correct conference ID The conference ID remains 
  167. in effect until the conference manager resets it to another 
  168. number or perhaps 0 to make it an unrestricted conference.
  169.  
  170.  
  171. CAP cap hold-down-time msg-string
  172. //
  173.  
  174. CAP is used to enforce transmission rate limits for those 
  175. participants that connect to your reflector.  If a 
  176. participant sets his maximum transmission rate above the cap 
  177. that you specified he will automatically be disconnected from 
  178. the reflector and prohibited to reconnect for the specified 
  179. hold-down-time.  Cap is specified in kilo bits per second and 
  180. hold-down time is specified in minutes.  The default value 
  181. for cap is 80 kilo bits per second and the default value for 
  182. hold-down-time is 1 minute.
  183.  
  184.  
  185. ADMIT ip-address msg-string
  186. //
  187.  
  188. ADMIT is another mechanism you can use to limit the 
  189. participants in a conference.  By adding an ADMIT IP address 
  190. line for each invited participant, the reflector will 
  191. restrict the conference to only those participants who have 
  192. an IP address which matches one of the IP addresses specified 
  193. by an ADMIT line.  The msg string is an ascii string 
  194. terminated by a carriage return followed by two back slashes.  
  195. This is the string that will appear on a participant's screen 
  196. if he tries to connect but he is not on the admit list.  
  197. Currently, there must be a message string specified with each 
  198. ADMIT in the configuration file, but only the message string 
  199. associated with the last ADMIT in the configuration file will 
  200. be used.  For now, that means you should just enter in some 
  201. dummy string for each ADMIT in the configuration file except 
  202. the last one.  In some future version of the reflector all 
  203. the message strings will be optional so that this nuisance 
  204. will go away. 
  205.  
  206.  
  207. MAX-PARTICIPANTS maxallowed msg-string
  208. //
  209.  
  210. MAX-PARTICIPANTS allows you to limit the load on your 
  211. reflector to the specified number of participants.  The 
  212. maxallowed range is 0 to 40, with the default equal to 20.  
  213. The msg string is an ascii string terminated by a carriage 
  214. return followed by two back slashes.  This is the string that 
  215. will appear on a participant's screen if he tries to connect 
  216. but the maximum number of allowed participants has been 
  217. exceeded.
  218.  
  219.  
  220. MAX-SENDERS maxsendersallowed msg-string
  221. //
  222.  
  223. MAX-SENDERS allows you to limit the number of video senders 
  224. on your reflector to the specified number of participants.  
  225. The maxsendersallowed range is 0 to 40, with the default 
  226. equal to 20.  The msg string is an ascii string terminated by 
  227. a carriage return followed by two back slashes.  This is the 
  228. string that will appear on a participant's screen if he tries 
  229. to connect as a sender but the maximum number of video 
  230. sending participants has been exceeded.
  231.  
  232.  
  233. MAX-LURKERS maxlurkersallowed msg-string
  234. //
  235.  
  236. MAX-LURKERS allows you to limit the number of receive only 
  237. participants on your reflector to the specified number of 
  238. participants.  The maxlurkersallowed range is 0 to 40, with 
  239. the default equal to 20.  The msg string is an ascii string 
  240. terminated by a carriage return followed by two back slashes.  
  241. This is the string that will appear on a participant's screen 
  242. if he tries to connect as a non video sender but the maximum 
  243. number of lurkers has been exceeded.
  244.  
  245.  
  246. LOG filename
  247.  
  248. The reflector logs a small amount of information such as each 
  249. participants arrival and departure from the conference in a 
  250. log file.  The default name for this file is reflect.log.  To 
  251. change the name of this file specify the LOG parameter with a 
  252. different file name.
  253.  
  254.  
  255. LOG-LIMIT log-file-line-limit
  256.  
  257. If you have a busy reflector running for several days the log 
  258. file can grow quite large.  Use LOG-LIMIT to limit the number 
  259. of lines in the log file.  The default is 10,000 lines of log 
  260. information.  After the log file line limit is reached the 
  261. reflector will erase the log file and start a new one with 
  262. the same name.  If you specify a log file line limit of 0, no 
  263. log file will be created.
  264.  
  265.  
  266. MOTD motd-string
  267. //
  268.  
  269. MOTD is used to specify the message of the day.  In any Mac 
  270. version of CU-SeeMe above 0.70, or an PC version above 0.34 
  271. the application will display any motd messages when a user 
  272. first connects to a reflector.  The motd can be up to 800 
  273. characters in length.  The message of the day string is an 
  274. ascii string terminated by a carriage return followed by two 
  275. back slashes.
  276.  
  277.  
  278.  
  279.  
  280. ADMIT-BCC-CLIENT ip-address
  281.  
  282. ADMIT-BCC-CLIENT is used to cause the reflector to send a 
  283. blind carbon copy of all of the CU-SeeMe streams to another 
  284. reflector.  This is used if you are putting on an event where 
  285. there are a small number of active participants and a large 
  286. number of passive viewers.  The primary conference is run off 
  287. of the main reflector.  This reflector is configured with one 
  288. or more ADMIT-BCC-CLIENT lists causing it to send CU-SeeMe 
  289. streams to other reflectors.  The passive audience then 
  290. connects to these other reflectors on the "reflector net" to 
  291. watch the main event.
  292.  
  293.  
  294. ADMIT-GENERAL-BCC count id
  295.  
  296. Often when setting up an event reflector you don't really 
  297. care which reflectors are going to be configured to receive 
  298. your feed in addition updating the configuration file becomes 
  299. tedious as new reflector sites ask to connect.  ADMIT-
  300. GENERAL-BCC allows you the freedom to specify how many feeds 
  301. you are willing to send out without having to be concerned 
  302. about the actuall ip addresses of the connecting reflectors.  
  303. The id field is a 16 bit value which you can use to make sure 
  304. that only those reflectors with the correct id will be 
  305. allowed to connect to yours.
  306.  
  307.  
  308. OBTAIN-BCC ip-address
  309.  
  310. OBTAIN-BCC is used to configure a reflector to receive a 
  311. blind carbon copy feed from another reflector which has been 
  312. configured with ADMIT-BCC, as explained above.
  313.  
  314.  
  315. OBTAIL-GENERAL-BCC ip-address id
  316.  
  317. OBTAIN-GENERAL-BCC is used to configure a reflector to 
  318. receive a blind carbon copy feed from another reflector which 
  319. has been configured with ADMIT-GENERAL-BCC, as explained 
  320. above.
  321.  
  322.  
  323. MC-OUT ttl multicast-addr
  324.  
  325. MC-OUT and MC-IN (see below) are similar to ADMIT-BCC-CLIENT 
  326. and OBTAIN-BCC client, but take advantage of IP Multicasting.  
  327. To use any of the multicast capabilities of the reflector, 
  328. you must first make sure that your reflector has been 
  329. compiled with the -DMULT switch, this causes the multicast 
  330. code to be compiled into the reflector.  Second, the 
  331. reflector host must support multicast. Consult with your 
  332. local UNIX guru to find out if your system is multicast 
  333. capable or not.  MC_OUT will send all CU-SeeMe streams to the 
  334. specified multicast address using the specified ttl (time to 
  335. live).
  336.  
  337.  
  338. MC-IN multicast-addr
  339.  
  340. MC-IN is used to configure a reflector to receive a multicast 
  341. stream put out by another reflector, as explained above.  MC-
  342. IN and MC-OUT should not be used together on the same 
  343. reflector.
  344.  
  345.  
  346. UNICAST-REF ip-address
  347.  
  348. UNICAST-REF is used to "tie together" two or more reflectors.  
  349. This feature is useful if you are running a conference whose 
  350. participants are spread out across the country.  For example, 
  351. if you have some folks on the east coast, another group in 
  352. California, and perhaps a third group in the south, each 
  353. group can connect to their local reflector and using UNICAST-
  354. REF you can connect all three reflectors together.  This 
  355. makes for a more efficient use of network bandwidth, rather 
  356. than having everyone connect to a single reflector.  Each 
  357. reflector should have a UNICAST-REF for each other reflector.
  358.  
  359.  
  360. MC-GROUP ttl multicast-addr
  361.  
  362. MC-GROUP is similar to UNICAST-REF, but takes advantage of IP 
  363. Multicasting.  Two or more reflectors can be "tied together" 
  364. using IP multicast.  Reflectors configured with MC-GROUP will 
  365. send out all CU-SeeMe streams to the specified multicast 
  366. address using the specified ttl, in addition they will accept 
  367. incoming CU-SeeMe streams from that multicast address.
  368.  
  369.  
  370. NO-LOCAL-SENDERS
  371.  
  372. NO-LOCAL-SENDERS is used in a configuration file that also 
  373. contains either OBTAIN-BCC or MC-IN.  NO-LOCAL-SENDERS sets 
  374. up a reflector that is only used in viewing a conference 
  375. taking place on a primary reflector.  Since the purpose is to 
  376. view the main event, you can disable local interaction among 
  377. those who have connected to watch the main event.  This will 
  378. reduce the load on your secondary reflector.
  379.  
  380.  
  381. ADMIT-SENDER ip-address
  382.  
  383. ADMIT-SENDER is used in conjunction with NO-LOCAL-SENDERS to 
  384. allow the specified ip-address to send video, while 
  385. restricting all other participants to receive only.  You may 
  386. have multiple ADMIT_SENDER entries in your configuration 
  387. file.  
  388.  
  389.  
  390. NV-UC-PORT port-number
  391.  
  392. Specifies the UDP port number to use when communicating with 
  393. nv via a unicast connection.
  394.  
  395.  
  396. NV-MC-PORT port-number
  397.  
  398. Specifies the UDP port number to use when communicating with 
  399. nv via a multicast connection.
  400.  
  401.  
  402. NV-MC-IN multicast-addr
  403.  
  404. Specifies a multicast address for receiving CU-SeeMe encoded 
  405. video from nv via the Mbone.
  406.  
  407.  
  408. NV-MC-OUT ttl multicast-addr
  409.  
  410. Specifies a ttl and a multicast address for sending CU-SeeMe 
  411. video to nv via the Mbone.  If both NV-MC-IN and NV-MC-OUT 
  412. are specified, then the multicast addresses must be 
  413. identical.
  414.  
  415.  
  416. NV-STREAMS number-streams
  417.  
  418. Specifies the maximum number of video streams to send to any 
  419. nv unicast client.  Since nv does not currently provide a 
  420. mechanism for pruning unwanted video streams, it's important 
  421. to limit the bandwidth sent to nv clients.  The default 
  422. number of streams sent is 4.  Note that if more than the 
  423. allowed number are available there is no control over which 
  424. will be sent.  The same set will be sent to all nv's which 
  425. connect. This facility is workable for having a conference 
  426. with a known set of nv and CU-SeeMe participants, or for 
  427. testing with nv on a public reflector, but not for general nv 
  428. participation in open reflector conferences.  It is a 
  429. temporary arrangement. 
  430.  
  431.  
  432. VAT-UC-PORT vat-port
  433.  
  434. Specifies the UDP port number to use when communicating with 
  435. vat via a unicast connection.
  436.  
  437.  
  438. VAT-MC-PORT port
  439.  
  440. Specifies the UDP port number to use when communicating with 
  441. vat via a multicast connection.
  442.  
  443.  
  444. VAT-MC-IN multicast-addr
  445.  
  446. Specifies a multicast address for receiving vat audio from 
  447. the mbone.
  448.  
  449.  
  450. VAT-MC-OUT ttl multicast-addr
  451.  
  452. Specifies a ttl and a multicast address for sending audio to 
  453. vat via the Mbone.  If both VAT-MC-IN and VAT-MC-OUT are 
  454. specified, the the multicast addresses must be identical.
  455.  
  456.  
  457. VAT-CONF-ID id
  458.  
  459. Specifies the conference id to use with vat.
  460.  
  461. MIN-MAC-VERSION version-number msg-string
  462. //
  463.  
  464. MIN-MAC-VERSION is used to ensure that all of the Mac clients 
  465. connecting to your reflector are at least at some minimum 
  466. version number.  This is useful if you are running a 
  467. conference and there is some feature in a later version of 
  468. CU-SeeMe, like audio, that you want to use during the 
  469. conference.  By setting a minimum version number only those 
  470. clients with a version of CU-SeeMe greater or equal to the 
  471. one designated, will be allowed to connect to the reflector. 
  472. The msg string is an ascii string terminated by a carriage 
  473. return followed by two back slashes. This is the string that 
  474. will appear on the user's screen if the version he using is 
  475. less then the specified version-number.  The version numbers 
  476. for Mac based CU-SeeMe are as follows: 70b1 is 12, 70b12 is 
  477. 18, 70b13 is 19, 70b14 is 22, 70b15 is 25.
  478.  
  479. MIN-PC-VERSION version-number msg-string
  480. //
  481.  
  482. MIN-PC-VERSION is used to ensure that all of the PC clients 
  483. connecting to your reflector are at least at some minimum 
  484. version number.  This is useful if you are running a 
  485. conference and there is some feature in a later version of 
  486. CU-SeeMe, like audio, that you want to use during the 
  487. conference.  By setting a minimum version number only those 
  488. clients with a version of CU-SeeMe greater or equal to the 
  489. one designated, will be allowed to connect to the reflector. 
  490. The msg string is an ascii string terminated by a carriage 
  491. return followed by two back slashes.  This is the string that 
  492. will appear on the user's screen if the version he using is 
  493. less then the specified version-number.  The current version 
  494. number for PC based CU-SeeMe0.34 is 2.
  495.  
  496.  
  497. DENY ip-address msg-string
  498. //
  499.  
  500. Deny causes the reflector to deny access to the client at the 
  501. specified IP address.
  502.  
  503.  
  504. REFMON Version 1.00
  505.  
  506. Refmon stands for reflector monitor, it is a program that is 
  507. used to monitor the state of your reflector.  Currently 
  508. refmon has one switch -s which is used to specify the host 
  509. name or IP address of the machine running the reflector.  For 
  510. example 
  511.  
  512. refmon -s hellbat.cit.cornell.edu
  513.  
  514. will start up a refmon to query the reflector running on 
  515. hellbat.cit.cornell.edu.  Once refmon is started up it 
  516. accepts commands, the commands cause a query to be sent to 
  517. the reflector and the reflector's response is printed out on 
  518. the screen.  The commands are the following:
  519.  
  520. quit
  521.     quits the refmon application.
  522.  
  523.  
  524. version
  525.     shows the version number of the reflector.
  526.  
  527.  
  528. who
  529.     shows a list of the participants currently connected to 
  530.     the reflector.
  531.  
  532.  
  533. maven
  534.     shows a list of all maven clients currently connected to
  535.      the reflector.
  536.  
  537.  
  538. uptime
  539.     shows the time that the reflector was started.
  540.  
  541.  
  542. term
  543.     kills the reflector application.
  544.  
  545.  
  546. param
  547.     prints out the configuration file.
  548.  
  549.  
  550. help
  551.     prints out this list of commands
  552.